Run Forester, Run Backwards! - (Competition Contribution)

This paper briefly describes the Forester tree automata-based shape analyser and its participation in the SV-COMP’16 competition on software verification. In particular, it summarizes the verification approach used by Forester, its architecture and setup for the competition, as well as its strengths and weaknesses observed in the competition run. The paper highlights the newly added counterexample validation and use of refinable predicate language abstraction. 1 Verification Approach Forest Automata. Forester implements a fully automated and sound shape analysis based on the notion of forest automata (FAs) [1]. FAs can represent sets of reachable configurations of programs with complex dynamic linked data structures (such as various kinds of lists, trees, skip lists, as well as combinations of such data structures). They have a form of tuples of tree automata (TAs). These tuples of TAs encode sets of heap graphs decomposed into tuples of tree components, whose leaves may refer back to the roots of the components (including roots of other components). The decomposition is based on cutting a heap graph at each cut-point, i.e., a node which is either pointed by some pointer variable or which has multiple incoming pointer edges. In order to encode complex heap graphs, FAs may be hierarchically structured in such a way that a higher-level FA may use other, lower-level FAs as alphabet symbols. These nested automata, called boxes, encode repetitive graph patterns and can be automatically learned using the approach proposed in [2]. In order to be as efficient as possible, Forester never determinises the TAs it works with. All needed operations, including inclusion checking and size reduction, are therefore implemented on non-deterministic TAs. For that, techniques such as antichainbased inclusion checking and simulation-based reduction are used. Counterexample Analysis and Refinement. In Forester, FAs are used within the framework of abstract regular tree model checking (ARTMC) [3]. ARTMC accelerates the computation of sets of reachable program configurations, represented by FAs, by abstracting their component TAs, which is done by collapsing some of their states. For deciding which TA states should be collapsed when performing ARTMC, multiple approaches have been proposed in the literature [3]. When Forester first participated in SV-COMP in 2015, it supported the simplest of these approaches based on collapsing states accepting the same languages of trees up to some height only. No checking of validity of counterexamples and no abstraction refinement was implemented then. In the version of Forester participating in SV-COMP’16, an approach for checking validity of counterexamples was added. It is based on a backward execution of the program being verified along the suspected counterexample. For that, it was needed to add a support for reverse execution of all program statements over FAs. Moreover, a support for intersection of FAs, not needed before, had to be added. Intersection of FAs is a feature needed to either derive a concrete program trace from the forward and backward symbolic executions, or determine that no such a trace exists since the intersection gets empty at some point in the traces. It turns out that intersecting FAs is a quite complex task, which has to, e.g., deal with the fact that the two FAs being intersected may use a different decomposition of the heap graphs they represent. Moreover, Forester has also been extended with the most advanced abstraction mechanism known in the context of ARTMC, namely predicate language abstraction. In its case, one collapses those TA states whose languages intersect the same predicate languages (represented also by TAs). The predicate languages to be used are learned in a counterexample guided refinement (CEGAR) loop from the TAs that are generated within backward executions of the program along spurious counterexample traces. Currently, the first execution of Forester uses the finite height abstraction, which is then refined in the further runs by combining it with the predicate language abstraction. More details on the mentioned checking of validity of counterexamples and the refinable predicate language abstraction used in the context of FAs are still to be published, but a preliminary description can be found in [6].